home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19960715-19961006 / 000102_news@columbia.edu _Tue Jul 30 13:42:40 1996.msg < prev    next >
Internet Message Format  |  2020-01-01  |  4KB

  1. Return-Path: news@columbia.edu
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30]) by watsun.cc.columbia.edu (8.7.5/8.7.3) with ESMTP id NAA11910 for <kermit.misc@watsun.cc.columbia.edu>; Tue, 30 Jul 1996 13:42:40 -0400 (EDT)
  3. Received: (from news@localhost) by newsmaster.cc.columbia.edu (8.7.5/8.7.3) id NAA28541 for kermit.misc@watsun; Tue, 30 Jul 1996 13:42:39 -0400 (EDT)
  4. Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
  5. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  6. Newsgroups: comp.protocols.kermit.misc,comp.dcom.modems
  7. Subject: Re: Problem getting 28800 bps in C-Kermit 5A(190) on a v.34 internal
  8. Date: 30 Jul 1996 17:42:17 GMT
  9. Organization: Columbia University
  10. Lines: 73
  11. Message-ID: <4tlhhp$fm8@apakabar.cc.columbia.edu>
  12. References: <CROTEN.96Jul24005129@crl.crl.com> <1996Jul28.193939.943@ia-us.com> <CROTEN.96Jul28153957@crl.crl.com> <1996Jul30.164039.1803@ia-us.com>
  13. NNTP-Posting-Host: watsun.cc.columbia.edu
  14. Xref: news.columbia.edu comp.protocols.kermit.misc:5674 comp.dcom.modems:146136
  15.  
  16. In article <1996Jul30.164039.1803@ia-us.com>,
  17. Glenn Herteg <glenn@lia.com> wrote:
  18. : >I get the same sort of behavior .. with an internal modem, low CPU loading, 
  19. : >and rtc/cts flow control.  You earlier mentioned that the misbehavior was, 
  20. : >you suspected, at the device-driver level.  Perhaps it is independent of 
  21. : >these other issues.  
  22. : Frank has indicated the likely problem; I'll upgrade my kermit and run
  23. : some tests.  I had not done the upgrade before because the version I use
  24. : seemed otherwise fine, there was a clear workaround, and I felt I had no
  25. : right to expect a protocol to work when I'm telling it to depend on a
  26. : transport known to be broken.  Frank seems to feel otherwise, so okay,
  27. : I'll take up the challenge.
  28. : (The other reason I didn't upgrade had to do with the default behavior
  29. : on transferring partial files.  It's possible in the 190 version to have
  30. : partial files left around, and you get no notice of this.
  31. :
  32. Right, the *default* changed.  This is to allow recovery of broken
  33. transmissions, a much asked-for feature.  You can, of course, restore the
  34. previous behavior of discarding patially received files by putting the
  35. following command in your .kermrc:
  36.  
  37.   set file incomplete discard
  38.  
  39. and/or you can test whether a transfer succeeded (even if you do keep
  40. the fragment from a failed transfer) using SHOW STATUS, IF SUCCESS ...,
  41. looking in the transaction log, or in any number of other ways, including...
  42.  
  43. : I suppose the fullscreen display would tell me that at the end of the
  44. : transfer.  But if I'm using an xterm [for instance; lots of terminals
  45. : have this "problem"] then the fullscreen display flips into an alternate
  46. : screen, which [kazaam!] disappears once the transfer is done.
  47. :
  48. Well, that's not nice of your xterm.  Using a normal terminal or emulator,
  49. this doesn't happen, and you have the entire transfer display to look at
  50. after the transfer is done.  Not a Kermit problem.
  51.  
  52. : There went my notification of success or failure.  [To fix this, I think a
  53. : simple success or failure notification, and the name of any partial file
  54. : left hanging around, ought to be repeated on the original screen once
  55. : fullscreen mode ends.]
  56. :
  57. And others think we are way too verbose already :-)  But that's what the
  58. macro language is for:
  59.  
  60.   define verbosesend send \%1, show status
  61.  
  62.   define verbosereceive receive, -
  63.     show status, -
  64.     xif fail { echo, echo PARTIAL file received: \v(filespec), echo }
  65.  
  66. By the way, the next release of C-Kermit will indeed have a CRC generation
  67. and checking feature, so you will be able to do the following to verify
  68. that a binary-mode transfer produced the desired result, assuming you have
  69. a Kermit client and a Kermit server that both support this feature:
  70.  
  71.   set file type binary
  72.   send (or get) (one or more files)
  73.   remote query kermit crc16
  74.   if not = \v(query) \v(crc16) echo CRC mismatch
  75.   else echo CRC comparison OK
  76.  
  77. (Replace the ECHO commands with whatever you need to handle failure and
  78. success.)
  79.  
  80. This feature uses the CRC-16 code that has proven itself portable to over
  81. 500 different platforms -- 16-bit, 32-bit, 64-bit -- over the past 10 years,
  82. so you don't have to worry about sign extension, endianness, word size or
  83. other problems that "man sum" hints at.  Plus, unlike "sum", it will be
  84. available in other operating systems besides just UNIX.
  85.  
  86. - Frank